1. Field of the Invention
The present invention pertains to the field of computer systems. More specifically, this invention relates to creation of microcode exception handler vectors using mode and fault information during execution within a processor.
2. Background Information
Typical prior art computer processors implement in-order instruction execution pipeline. An in-order processor usually fetches an instruction stream from a memory, and executes each instruction in the instruction stream according to a sequential program order. Such in-order instruction execution ensures that data dependencies among the instructions are strictly observed.
A processor may perform out-of-order instruction execution to increase instruction execution performance. Such a performance executes ready instructions in the instruction stream ahead of earlier instructions in the program order that are not ready. A ready instruction is typically an instruction having fully assembled source data in available execution resources.
Such out-of-order execution improves processor performance because the instruction execution pipeline of the processor does not stall while awaiting source data or execution resources for a non-ready instruction. For example, an instruction in the instruction stream may require source data from a processor register, wherein the processor register is loaded by a pending external memory fetch operation. Such an instruction awaiting the results of the external memory fetch does not stall the execution of later instructions in the instruction stream that are ready to execute.
A processor may also perform speculative instruction execution to increase instruction execution performance. Such a processor typically determines a speculative execution branch through a program by predicting the result of branch instructions. Such a processor fetches an instruction stream from a memory, predicts a branch result for each branch instruction, and continues fetching and executing the instruction stream according to the predicted branch result. Such speculative execution increases processor performance because the instruction fetch pipeline does not stall during the resolution of branch instructions.
A processor that performs both speculative and out-of-order instruction execution generates speculative result data in an out-of-order sequence in relation to the original program order. The result data is out-of-order because the instructions that cause generation of the result data are executed out-of-order. The result data is speculative until the branch prediction or predictions that caused speculative execution of the instructions is resolved.
Such a speculative out-of-order processor requires a mechanism for coordinating exceptions that occur during the speculative out-of-order execution of the instructions. These exceptions include, for example, software traps and software faults. An example of a software fault is a page fault during a memory access. An example of a trap is a data breakpoint trap. In addition, such a speculative out-of order processor must coordinate the handing of asynchronous events such as interrupts.
When an exceptions occurs in prior art in-order machines, such as those conforming to the Intel brand processor architecture, a special form of far call, the exception handler call, is performed to the exception handler. This far call pushes a return CS and EIP value on to the stack, pushes an EFLAGS register value onto the stack, and branches to an address specified by a CS and EIP value found in the IDT. One prior art method of handling exceptions is described in chapter 9 of the i486 Programmer's Reference Manual. Intel type architecture exceptions can be grouped into four categories:
Faults--exceptions detected while executing an instruction. The instruction is terminated immediately and those state changes made by the instruction are not committed. Return EIP points to the instruction which caused the exception. PA1 Traps--exceptions detected while executing an instruction which are held pending until instruction execution completes. State changes made by the instruction are committed before the exception is handled. Return EIP points to the instruction following the one which caused the exception. PA1 Software Interrupts--exceptions caused by INTn instruction in the Intel architecture. Return EIP points to the instruction following the INTn. PA1 Hardware Interrupts--exceptions caused by the assertion of the INT or NMI pin. The EIP points to the instruction to be executed after servicing the interrupt.
In addition to the differences in the return EIP value pushed on the stack, each different type of exception can require that different values stored in the EFLAGS register in the Intel architecture processor be pushed and that different protection checks be performed on the value obtained from the IDT. They also may require that certain control registers be loaded with data pertaining to the exception and that a special error code be pushed on to the stack for certain exception types. This requires that microcode perform different actions during the exception handler call based on the type of the exception which occurred.
In addition to these differences, different exception handler call actions are required based on whether the Intel brand processor is in Real, Protected, Virtual-8086, or Virtual Mode Extensions (VME) mode at the time the exception occurred. These differences can include different methods of obtaining the CS and EIP information from the IDT, additional protection checks required in some modes, and different EFLAGS register values after the call based on mode and exception type.
Previous processors compatible with the Intel architecture directed microcode execution to different exception handlers based on the type of exception when the exception was posted, and relied on conditional microcode branches within the exception handers to select among the mode specific actions which might need to be performed. This technique suffers from performance penalties in out-of-order speculative execution processors because of the length of the pipeline and the number of buffers which must be flushed during the occurrence of exceptions. The conditional branches based on mode within each handler also incur a high penalty because of these flushing actions.
Thus, there is a need for a processor which can perform different actions based on mode and exception type occurring in a processor, but yet, avoid conditional branching within exception handlers in order to maintain performance at a high level in a speculative out-of order processor.